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Abstract

   This document describes the conventions for using ChaCha20-Poly1305
   Authenticated Encryption in the Cryptographic Message Syntax (CMS).
   ChaCha20-Poly1305 is an authenticated encryption algorithm
   constructed of the ChaCha stream cipher and Poly1305 authenticator.
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1.  Introduction

   This document specifies the conventions for using ChaCha20-Poly1305
   Authenticated Encryption with the Cryptographic Message Syntax (CMS)
   [CMS] authenticated-enveloped-data content type [AUTHENV].

   ChaCha [CHACHA] is a stream cipher developed by D. J. Bernstein in
   2008.  It is a refinement of Salsa20, which is one of the ciphers in
   the eSTREAM portfolio [ESTREAM].

   ChaCha20 is the 20-round variant of ChaCha; it requires a 256-bit key
   and a 96-bit nonce.  [FORIETF] provides a detailed algorithm
   description, examples, and test vectors of ChaCha20.

   Poly1305 [POLY1305] is a Wegman-Carter, one-time authenticator
   designed by D. J. Bernstein.  Poly1305 produces a 16-byte
   authentication tag; it requires a 256-bit, single-use key.  [FORIETF]
   also provides a detailed algorithm description, examples, and test
   vectors of Poly1305.

   ChaCha20 and Poly1305 have been designed for high-performance
   software implementations.  They can typically be implemented with few
   resources and inexpensive operations, making them suitable on a wide
   range of systems.  They have also been designed to minimize leakage
   of information through side channels.
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1.1.  The ChaCha20 and Poly1305 AEAD Construction

   ChaCha20 and Poly1305 have been combined to create an Authenticated
   Encryption with Associated Data (AEAD) algorithm [AEAD].  This AEAD
   algorithm is often referred to as AEAD_CHACHA20_POLY1305, and it is
   described in [FORIETF].

   AEAD_CHACHA20_POLY1305 accepts four inputs: a 256-bit key, a 96-bit
   nonce, an arbitrary-length plaintext, and an arbitrary-length
   additional authenticated data (AAD).  As the name implies, a nonce
   value cannot be used securely more than once with the same key.

   AEAD_CHACHA20_POLY1305 produces two outputs: ciphertext of the same
   length as the plaintext and a 128-bit authentication tag.

   AEAD_CHACHA20_POLY1305 authenticated decryption processing is similar
   to the encryption processing.  Of course, the roles of ciphertext and
   plaintext are reversed, so the ChaCha20 encryption function is
   applied to the ciphertext, producing the plaintext.  The Poly1305
   function is run over the AAD and the ciphertext, not the plaintext,
   and the resulting authentication tag is bitwise compared to the
   received authentication tag.  The message is authenticated if and
   only if the calculated and received authentication tags match.

1.2.  ASN.1

   CMS values are generated using ASN.1 [X680], which uses the Basic
   Encoding Rules (BER) and the Distinguished Encoding Rules (DER)
   [X690].

1.3.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [STDWORDS].
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2.  Key Management

   The reuse of an AEAD_CHACHA20_POLY1305 nonce value with the same key
   destroys the security guarantees.  It can be extremely difficult to
   use a statically configured AEAD_CHACHA20_POLY1305 key and never
   repeat a nonce value; however, the CMS authenticated-enveloped-data
   content type supports four key management techniques that allow a
   fresh AEAD_CHACHA20_POLY1305 key to be used as the
   content-authenticated-encryption key for a single protected content:

      Key Transport: the fresh content-authenticated-encryption key is
         encrypted in the recipient's public key;

      Key Agreement: the recipient's public key and the sender's private
         key are used to generate a pairwise symmetric key-encryption
         key, then the fresh content-authenticated-encryption key is
         encrypted in the pairwise symmetric key;

      Symmetric Key-Encryption Keys: the fresh content-authenticated-
         encryption key is encrypted in a previously distributed
         symmetric key-encryption key; and

      Passwords: the fresh content-authenticated-encryption key is
         encrypted in a key-encryption key that is derived from a
         password or other shared secret value.

   In addition to these four general key management techniques, CMS
   supports other key management techniques.  See Section 6.2.5 of
   [CMS].  Since the properties of these key management techniques are
   unknown, no statement about their support of fresh
   content-authenticated-encryption keys can be made.  Designers and
   implementers must perform their own analysis if one of these other
   key management techniques is supported.

3.  Using the AEAD_CHACHA20_POLY1305 Algorithm with AuthEnvelopedData

   This section specifies the conventions employed by CMS
   implementations that support the authenticated-enveloped-data content
   type and the AEAD_CHACHA20_POLY1305 algorithm.

   The AEAD_CHACHA20_POLY1305 algorithm identifier is located in the
   AuthEnvelopedData EncryptedContentInfo contentEncryptionAlgorithm
   field.
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   The AEAD_CHACHA20_POLY1305 algorithm is used to (1) authenticate the
   attributes located in the AuthEnvelopedData authAttrs field, if any
   are present, (2) encipher the content located in the
   AuthEnvelopedData EncryptedContentInfo encryptedContent field, and
   (3) provide the message authentication code (MAC) located in the
   AuthEnvelopedData mac field.  The authenticated attributes are
   DER encoded to produce the AAD input value to the
   AEAD_CHACHA20_POLY1305 algorithm.  The ciphertext and the MAC are the
   two outputs of the AEAD_CHACHA20_POLY1305 algorithm.  Note that the
   MAC, which is called the authentication tag in [FORIETF], provides
   integrity protection for both the AuthEnvelopedData authAttrs and the
   AuthEnvelopedData EncryptedContentInfo encryptedContent.

   Neither the plaintext content nor the optional AAD inputs need to be
   padded prior to invoking the AEAD_CHACHA20_POLY1305 algorithm.

   There is one algorithm identifier for the AEAD_CHACHA20_POLY1305
   algorithm:

      id-alg-AEADChaCha20Poly1305 OBJECT IDENTIFIER ::=
          { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
            pkcs9(9) smime(16) alg(3) 18 }

   The AlgorithmIdentifier parameters field MUST be present, and the
   parameters field MUST contain an AEADChaCha20Poly1305Nonce:

      AEADChaCha20Poly1305Nonce ::= OCTET STRING (SIZE(12))

   The AEADChaCha20Poly1305Nonce contains a 12-octet nonce.  With the
   CMS, the content-authenticated-encryption key is normally used for a
   single content.  Within the scope of any content-authenticated-
   encryption key, the nonce value MUST be unique.  That is, the set of
   nonce values used with any given key MUST NOT contain any duplicate
   values.

4.  S/MIME Capabilities Attribute

   Section 2.5.2 of RFC 5751 [MSG] defines the SMIMECapabilities
   attribute, which is used to specify a partial list of algorithms that
   the software announcing the SMIMECapabilities can support.  When
   constructing a CMS signed-data content type, compliant software MAY
   include the SMIMECapabilities signed attribute to announce support
   for the AEAD_CHACHA20_POLY1305 algorithm.

   The SMIMECapability SEQUENCE representing the AEAD_CHACHA20_POLY1305
   algorithm MUST include the id-alg-AEADChaCha20Poly1305 object
   identifier in the capabilityID field and MUST omit the parameters
   field.
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   The DER encoding of an SMIMECapability SEQUENCE is the same as the
   DER encoding of an AlgorithmIdentifier.  The DER encoding for the
   AEAD_CHACHA20_POLY1305 algorithm in the SMIMECapability SEQUENCE (in
   hexadecimal) is:

      30 0d 06 0b 2a 86 48 86 f7 0d 01 09 10 03 12

5.  IANA Considerations

   IANA has added the following entry in the "SMI Security for S/MIME
   Algorithms (1.2.840.113549.1.9.16.3)" registry:

      18   id-alg-AEADChaCha20Poly1305         RFC 8103

   IANA has added the following entry in the "SMI Security for S/MIME
   Module Identifier (1.2.840.113549.1.9.16.0)" registry:

      66   id-mod-CMS-AEADChaCha20Poly1305     RFC 8103

6.  Security Considerations

   The CMS AuthEnvelopedData provides all of the tools needed to avoid
   reuse of the same nonce value under the same key.  See the discussion
   in Section 2 of this document.  RFC 7539 [FORIETF] describes the
   consequences of using a nonce value more than once:

      Consequences of repeating a nonce: If a nonce is repeated, then
      both the one-time Poly1305 key and the keystream are identical
      between the messages.  This reveals the XOR of the plaintexts,
      because the XOR of the plaintexts is equal to the XOR of the
      ciphertexts.

   When using AEAD_CHACHA20_POLY1305, the resulting ciphertext is always
   the same size as the original plaintext.  Some other mechanism needs
   to be used in conjunction with AEAD_CHACHA20_POLY1305 if disclosure
   of the size of the plaintext is a concern.

   The amount of encrypted data possible in a single invocation of
   AEAD_CHACHA20_POLY1305 is 2^32-1 blocks of 64 octets each, because of
   the size of the block counter field in the ChaCha20 block function.
   This gives a total of 247,877,906,880 octets, which is likely to be
   sufficient to handle the size of any CMS content type.  Note that the
   ciphertext length field in the authentication buffer will accommodate
   2^64 octets, which is much larger than necessary.

   The AEAD_CHACHA20_POLY1305 construction is a novel composition of
   ChaCha20 and Poly1305.  A security analysis of this composition is
   given in [PROCTER].
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   Implementations must randomly generate content-authenticated-
   encryption keys.  The use of inadequate pseudorandom number
   generators (PRNGs) to generate cryptographic keys can result in
   little or no security.  An attacker may find it much easier to
   reproduce the PRNG environment that produced the keys, searching the
   resulting small set of possibilities rather than "brute force"
   searching the whole key space.  The generation of quality random
   numbers is difficult.  RFC 4086 [RANDOM] offers important guidance in
   this area.
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Appendix A.  ASN.1 Module

   CMS-AEADChaCha20Poly1305
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
         pkcs-9(9) smime(16) modules(0) 66 }

   DEFINITIONS IMPLICIT TAGS ::= BEGIN

   IMPORTS
      CONTENT-ENCRYPTION
      FROM AlgorithmInformation-2009
          { iso(1) identified-organization(3) dod(6) internet(1)
            security(5) mechanisms(5) pkix(7) id-mod(0)
            id-mod-algorithmInformation-02(58) };

   -- EXPORTS All

   AEADContentEncryptionAlgs CONTENT-ENCRYPTION ::=
       { cea-AEADChaCha20Poly1305, ... }

   cea-AEADChaCha20Poly1305 CONTENT-ENCRYPTION ::= {
       IDENTIFIER id-alg-AEADChaCha20Poly1305
       PARAMS TYPE AEADChaCha20Poly1305Nonce ARE required
       SMIME-CAPS { IDENTIFIED BY id-alg-AEADChaCha20Poly1305 } }

   id-alg-AEADChaCha20Poly1305 OBJECT IDENTIFIER ::=
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
         pkcs9(9) smime(16) alg(3) 18 }

   AEADChaCha20Poly1305Nonce ::= OCTET STRING (SIZE(12))

   END
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